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ABSTRACT 



Disclosed are a method and a system for transmitting a 
message or data packet from a single sender (21) to a 
plurality, Le. a group of receivers, usually called mul- 
ticasting, within a conventional unicast transmission 
network, i.e. a networic basically not equipped to handle 
such multicast transmissions, consisting of a plurality of 
subnetworks (22-24). The nodes or gateways (25-29) 
connecting the subnetworks maintain tables of multicast 
receiving stations (or groups of such) and the header of 
each message includes information defining the groups 
of the addressed multicast receiving stations. 
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network (the MPTN); the gateways are connected via 

ESTER-DOMAIN MULTICAST ROUTING the third subnetwork 18, e.g. a Transmission Control 

Program/Internet Protocol (TCP/IP) network. 

DESCRIPTION A key function of the MPTN gateways 16 and 17 is to 

1. Reld of the Invention ^ route messages from their source (e.g., the client appli- 
In computer networks, routing protocols are used to ^^on 12) to the destination (e.g., the server application 

distribute information that allows determination of how 14). This problem is difficult for the following reasons, 

to send a data packet or a message from any point in that A path between the source and destination must be 

network to its intended destination. In many cases, a found that satisfies the requirements of the application 

data packet or message is sent from a single source, ihe (e.g., security, speed, reliability), 

sender, to a smgle receiver; this is usually called unicast- The MPTN may be very large, with many subnet- 

ing. Today's computer networks have elaborate routing works and gateways. This can result in a very complex 

protocols to support or assure safe, fast, and reliable network topology, and therefore complex routing deci- 

execution of such unicast transmissions. If a data packet sions need to be made at the gateways, 

or message must, however, be sent from a single sending Due to link and node failures, or the installation of 

source to a group of receiving stations within a network new equipment, the topology, and thus the correct 

- usually called multicasting - it is very inefficient, if at routing decisions, change in real time, 

all possible, to rely on traditional unicast routing proto- To solve these problems, AtPTN gateways make use 

cols for this purpose. For this, the present mvention of the routing protocol mentioned above that was stan- 

provides a solutron; it relates to multicasting, in particu- 20 ^ardized by the International Standards Organization, 

lar to a method of multicasting messages in a complex called the Inter-Domain Routing Protocol (DORP), 

network that is originally equipped only for unicast IDRP defines the formats and procedures of a protocol 

t ransmissi on. for routing from a single source to a single destination in 

2. Background and Objects of the Invention ^ network of arbitrary topology and she However. 
Existing steteof-the-ad routing protocols, such as the 25 j^^^ support multicasting, that is, delivery of 

Inter-Domain Routing Protocol (IDRP), as disclosed ^ message from a single source to multiple destinations. 
e.g. m ISO 'Tuformation Processmg System- On the other hand, multicasting is essential in MPTN 
s^Telecc^unications and Inform^on Exchange for a number of reasons. First, some subnetworks sup- 
between Systems-Protocol for the Exchange Inter- multicasting and, therefore, applications running 
Domam Routmg formation Among ^termedi^ 30 those subnetworks take advantage of this feature. In 
flSS'cSK^^^^^ ordertopro^adecom.ect.^ 

framework for routmg umcast packets, that is, packets ^^^^^ .jw^uu, avui^ ^^^^i *uv 

sent to a single destination. 35 ^n multicastmg. For example, protocols for locat- 

Often, a key requirement of computer networks in "T^ff^'^T ^^^'^ ^ 

general, and of ^pUcant's Multi-Protocol Transport dism^uted to aU gatew^ attached to subnetwori^ m 

Network (abbreviated MPTN in the following) specifi- ^^^^ might be located, • . ^ , 

cally, is to allow the multicasting of data packets, which . Some examples of the problen^ associated with mul- 

are sent from a particular source to a group of destina- 40 ticastmg m an mternetwork enviromnent arenow de- 

tions. Generally speaking, this mvention gives a solu- scribed makmg reference to the simple MPTN illus- 

tion to this requirement by teaching a method of and a ^ 2. In tiiis example, a multicast is imtiated 

system for multicasting usmg a set of new protocols in t)y an appUcation m subnetwork W (21) that should be 

combmation with existing routing protocols (e.g. deUvered to destinations in subnetworks X (22) and 2 

IDRP) to support multicasting in a computer network 45 W- There are no destinations in subnetwork Y (23). 

of arbitrary size and topology. It has characteristics problems associated with such an operation m- 

which make it suitable for such an environment that are elude: 

not found in any existing multicasting protocols. I* acceptable to generate separate (unicast) 
In the following, background and objects of the in- messages to all destinations since tiiis would create an 
vention shall be described in more detail. It should be 50 unnecessary load on the MPTN resources. For exam- 
understood, however, that the invention is not in any ple, in FIG. 2, such a unicast strategy would necessitate 
way restricted to use within the type of network de- message for each destination be sent on the link 
scribed hereinbelow. Further examples can be found in between gateway A (25) and gateway B (26) instead of 
other pads of the description. ^ single multicast message. 

A widely used protocol set such as IBM's Multi- 55 It is not acceptable to multicast the message to every 

Protocol Transport Network provides connectivity-to subnetwork in the MPTN. In the example, subnetwork 

computer applications, regardless of the network to Y (23) should not receive a multicast destined only to 

which they are attached. Thus, as illustrated in FIG. 1, nodes m subnetworks X (22) and Z (24). Although not 

two applications attached to different subnetworks in illustrated by the example, it is clear that in a large 

the same MPTN 11 can communicate. As shown in 60 MPTN with many subnetworks and many different 

FIG. 1, a client application 12 attached to a first subnet- multicast groups, such a flooding strategy would not be 

work 13, e.g. a NetBIOS subnetwork (a trademark of acceptable. 

the applicant), can communicate with a compatible A given packet should only be multicast once to a 
server application 14 attached to a second subnetwork given subnetwork. In the example network, there are 
15, e.g. a System Network Architecture (SNA, which is 65 two paths from gateway B (26) to subnetwork X (22), 
also a trademark of the applicant) subnetwork. MPTN via gateway D (28) and via gateway C (29) direct Sub- 
gateways 16 and 17 are required to join the three differ- network X (22) should, however, only receive a single 
ent subnetworks 13, 15, and 18 into a smgle logical copy of the multicast from the source in subnetwork W 
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(21). This rule must hold regardless of the number of The following routing protocols used in IP networks 
gateways attached to subnetwork X (22), or the number are all based on a distance-vector (sometimes also called 
of paths between a source and a particular destination path-vector) routing scheme like that used in BDRP: 
subnetwork. This is important to minimize the load Routing Information Protocol (RIP)» as described by 
placed on subnetworks due to multicast traffic, and to 5 CX. Hedrik in ••Routing Information Protocol", RFC 
avoid duplication of packet delivery which may neces- 1058 (Request for Comments), NIC (Network Informa- 
sitate error recovery, protocols for some applications. tion Center), June 1988. 

Hello Routing Protocol, disclosed by D.L. Mills in 
PnorArt "Experimental Multiple Path Routing Algorithm", 

For a better understanding of the invention, solutions 10 RFC 981, NIC, March 1986. 
for multicasting messages in other environments, and Border Gateway Protocol (BGP), described by K. 
existing solutions in internetworking environments will Lougheed and Y. Rekhter in '•Border Gateway Proto- 
be reviewed. col (BGP)", RFC 1163, NIC. June 1990. 

Gateway-Gateway Protocol (GGP),as disclosed by 
Local Area Networks (LANs) Hinden and A. Sheltzer in "DARPA Internet 

LANs arc a very special type of subnetworks ance Gateway**, RFC 823, NIC, September 1982, 
they naturally support a broadcast function, such that a As will be apparent later, the present invention pro- 
single message is eaaly delivered to all nodes. The most vides a solution directly applicable to all networks 
common LAN multicast strategy is therefore to broad- based on the above (and equivalent) routing protocols, 
cast messages, and let each attached computer filter 20 IP multicast algorithms have been developed primar- 
those messages not required by local users. An example ily for use with the Routing Information Protocol as 
is given by S.R Deering and D.R. Cheriton in "Mul- disclosed by C.L. Hedrik, cited above, but are usable 
ticast Routing in Datagram Internetworks and Ex- with the other distance-vector routing algorithms as 
tended LANs", ACM Transactions on Computer Sys- well. IP multicast algorithms (see, e.g. S,E. Deering and 
terns , Vol. 8, No. 2, pp. 85-110, ACM, May 1990. How- 25 D.R. Cheriton, cited abov^ S.E. Deering: "Host Exten- 
ever, such a strategy seems unsuitable for a large inter- . sions for IP Multicasting", RFC 1112, NIC, August 
network, as previously explained. It should also be men- 1988; L. Hughes and P. Thomlinson: "A Multicast In- 
tioned that essentially the same observations hold for temetwork Routing Algorithm". Proceedings of the 
Metropohtan Area Networks (MANs). IFIP WG 6.4 Conference on High Speed Networking, 

When LAN segments are interconnected by bridges, 30 18-22 March 1991, Berlin, pp. 183-200; D. Waltzman, 
these can selectively filter LAN messages so that they C, Partridge, and S.E. Deering: ''Distance Vector Mul- 
are only broadcast on segments where at least one node ticast Protocol", RFC 1075, NIC, November 1988) are 
is a destination for a multicast. These protocols work as all variants of the Reverse Path Broadcasting algorithm 
follows (see Deering and Cheriton, cited above, for described by Y.K. Dalai and R-M. Metcalfe m "Reverse 
variations on this basic algorithm): 35 Path Forwarding of Broadcast Packets", Communica- 

1. Group members broadcast ihdi existence on the tions of the ACM, VoL 21, No. 12, pp. 1040-1048, 
LAN to which they are attached. These broadcasts are ACM, December 1978. This algorithm is similar to the 
forwarded by bridges onto all LAN segments so that all LAN multicast algorithm in that a spanning tree is used 
bridges can learn tile location of group members. to distribute the multicast packets, however it contains 

Z When a multicast packet for a group is received, 40 additional features to solve some of the problems associ- 
only bridges on the path to one or more members of that ated with LAN multicasting. In brief, the algorithm 
group forward the packet Thus, flooding of all LAN works as follows (see S.E. Deering and D.R. Cheriton, 
segments for each multicast is avoided. cited above, for a more detailed description): 

A restriction of such LAN-based multicasting is that 1. Multicast packets are initially broadcast to all sub- 
no loops are allowed in the topology, Le. there cannot 45 networks in the internetwork. Packets are broadcast on 
be multiple paths via bridges between any two LAN a least-cost spanning tree. When a router receives a 
stations. This is required since otherwise the sunple multicast packet from some source "S", it knows that it 
forwarding scheme used by the LAN bridges would is on the spanning tree for multicasts originating from S 
result in packets being broadcast forever around any Lf its routing tables indicate that it can reach node S with 
such loop. Such a scheme is unsuitable for multicasting 50 a lower cost than all other routers attached to a given 
in a large internetwork since aU traffic would be forced subnetwork (this information is available in the normal 
to take the same path through the internetwork thereby IP routing tables). If so, that router forwards the mul- 
creating an unacceptable load on the involved links. ticast packets on the subnetwork in question. It was 
Algorithms exists which allow loops to exist in the shown by S.E. Deering and D JL Cheriton, cited above, 
LAN topology, but a single set of bridges is selected 55 that this algorithm results in the multicast packet being 
that form a loop-free spanning tree for forwarding mul- distributed to each subnetworic in the internetwork with 
ticasts. Thus, all multicast traffic is still forced to follow minimum cost. 

a single path along the branches of the spanning tree. An cAtvious improvement of this scheme compared to 

. . the LAN multicasting schemes b that while here the 

Multicastmg m the Internet ^ multicast spanning tree is fixed for a given source, it is 

Multicasting algorithms exist that work with routing not the same for all sources. Thus multicast traffic is 
protocols used in Internet Protocol (IP) networks. BP distributed over many different paths in the network, 
networks provide routing and relaying of packets 2. In order to avoid broadcasting multicast packets to 
(called datagrams) over a general topology network subnetworks that do not have members in the specified 
consisting of LANs, point-to-point Hnks, and even sub- 65 group, a scheme is used whereby routers that receive a 
networks such as X.25. An IP internetwork consists of multicast for a particular group that do not lie on a 
a collection of such subnetworks interconnected by IP branch of the multicast tree that leads to any members 
routers. of that group discard the multicast (there is obviously 
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no need to forward it) and report to the predecessor in munications and Information Exchange between Sys- 

the multicast tree that this branch of the tree may be terns — Intermediate System to Intermediate System 

pruned. This process begins with routers attached to Intra-Domain Routing Protocol for Use in Conjunction 
"leaf subnetworks" (subnetworks that are at the end of with the Protocol for Providing the Connection", 

their respective branches owl the tree), and works its 5 ISO/DIS 10589, 1990, or any other similar protocol, 

way up the branch as far as possible to restrict the distri- such as those used in IP networks referenced above, 

bution of multicast traffic to where it is required. supports multicasting in large internetworks. This solu- 

The IP multicast schemes have the following draw- tion is also usable with link-state routing protocols, such 

backs: as OSPF developed for IP networks (described by J. 

Initially, multicasts from a given source to a given 10 Moy in "OSPF Version 2", RFC 1247, NIC, July 1991) 

group must be broadcast to the entire internet until the and the OSI IS-IS protocol (described in ISO/DIS 

multicast tree for that sourc&destination pair is pruned. 10589, cited above) and are thus applicable to a wide 

The scheme requires that information used for prun- range of internetworking environments. Within the 

ing the multicast trees be discarded after some time so invention, three new types of protocols are presented: 

that new members that loin the network on a previously 15 1. for the distribution of routing information based on 

pruned tree branch will eventually start receiving the network topology and the location of multicast group 

multicasts. Thus, multicasts trees are continuously re- members, and for the creation of routing tables using 

built and repruned, creating considerable oveihead on this information; 

the network Knks and processing nodes. 2. for efficiently forwarding multicast packets to all 

Multicast trees exist for each source-multicast group 20 members of a multicast group given the routing infor- 

pair. That is, a separate logical multicast tree exists for mation front tile first st^; and 

each different source that multicasts to a given group. 3. for enabling the multicast protocols to be used in 

Titus routing nodes may have to Tnaintflm an extremely the MPTN environment. 

large database for pruned multicast trees. Details and examples of the invention will be de- 
For these reasons such protocols or algorithms seem 25 scribed in the following in connection with the draw- 
unsuitable for use in the MPTN and similar architec- ings. 

tures. A useM algoriaim should be able to utilize tl« DRAWINGS FIG. 1 illustrates a multi-protocol 

Ins^elSetan. the following goals or objects of 30 subnetworks (already dbcn^ with the prior art 

the invention can be identified as requirements for pro- 

viding multicast service: FIG. 2 illustrates an example for another MPTN (also 

1 . Multicast packets must not be broadcast to all sub- already discussed above); 

networks, and in fact should be restricted to being sent FIG. 3 illustrates an example of the information 

only to subnetworks that have a multicast group mem- 35 learned by gateways from attached subnetworks; 

ber. FIG. 4 illustrates a detail in a subnetwork, namely all 

2. Each multicast packet must be delivered exactiy nodes with a common address prefix in such a subnet- 
once to each destination subnetwork (Le. duplicate mul- work; 

ticast packets must not be created), FIG. 5 illustrates various nodes with a given address 

3. The protocols should not require any centralized 40 prefix in different subnetworks; 

elements. They should be completely distributed. FIG. 6 illustrates the so-called MPTN split net ID 

4. The protocols should not require computation of a support 

spanning tree from a caitraHzed database. FIGS. 2 and 3 show essentially the same arrange- 

5. Routing decisions for multicast packets must be mcnt, the reference numbers are chosen such that the 
flexible. Distribution of all multicasts over a fixed span- 45 last digit of each number identifies the same part in each 
ning tree for exanq)le is not acceptable, figure, i.e. •'21" in FIG. 2 is the same part as "31" in 

6. The number of packets distributed must be mini- FIG. 3. 

mized. In particular, it b not ac^table to generate a DKTAILED DESCRIPTION 
separate umcast packet for each destmation. 

7. The cost of distributing the multicast packets must 50 The following section is divided into four pads. The 
be minimized Thus, a good path must be taken from the first pad, entitied "Routing Information", describes the 
multicast source to each destination. routing information that is distributed and the tables 

^ „ , ^„ „„ „^^^vT that are created for routing multicast packets. The sec- 

SUMMARY OF THE INVENTION ^^itled "Multicast Packet Forwarding", dc 

In brief, the present invention achieves the above 55 scribes the procedures for using the created tables to 
objects by a m^od and a system for multicasting a route mxdticast packets. Then, in the third pad, entitled 
message from a sending station to a plurality of receiv- "Multicast with Reduced Routing information:", a de- 
ing stations within a conventional unicast message scription is given ofhow the amount of routing informa- 
transmission network using existing protocols by, at tion required for the multicasting protocols can be re- 
least in certain nodes within the network, maintaining 60 duced. Finally, in part four, entitied "MPTN Use of 
tables of subnetworks with multicast receiving stations Multicast", an example is given ofhow MPTN uses the 
or tables of multicast receiving stations and by including protocols described in this invention, 
appropriate routing information in the header of mul^ Information 
ticast messages, as fiirther defined m the clanns. *^'^unu5 * « 

With this invention, a solution is presented that, when 65 A brief description of the Inter-Domain Routing 

used m combmation with distance-vector routing proto- Protocol (IDRP) protocol is provided so that the inven- 

cols such as the standard OSI IDRP routing protocol, tion may be better understood. Further details can be 

disclosed in ISO "Information Technology— Telecom- found in ISO/DIS 10589, referred to above. 
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IDRP distributes routing iiiformation between gate- The reachability information in an Update PDU con- 
ways in so-called Update PDUs, i.e. Update Protocol taining groupids consists of only the groupids and (one 
Data Units. Update PDUs contain the following fields of) the address prefix(es) unique to the end systems in 
that are relevant to the invention. the subnetwork reporting the groupids, so that all gate- 

1. Reachability Information: this field specifies the 5 ways will be able to build an association between the 
resources that can be reached along the path specified m subnetwork prefix and the groupids reachable in that 
this Update PDU. It can be the address of a specific end subnetworL 

system, or it can be the prefix common to the addresses The Update PDU constructed in this manner is deliv- 
used by a set of end systems. All systems whose address ered with the reachability information Held unchanged 
contains a given prefix reside in the same subnetwork, 10 to all gateways according to the existing IDRP proto- 
and therefore this prefix umquely identifies this subnet- cols. Note that this Update PDU construction is al- 
work. A type field is defined in the reachability infor- lowed by the IDRP standard, and that no other changes 
mation which indicates that the reachability informa- to the Update PDU construction or distribution are 
tion is an address prefix (type = O). Thus, different types required. 

of reachability information could be distributed in Up- 15 In the example shown in FIG. 3, gateway C (39) 
date PDUs by defining a new type code. would create an Update PDU with the following reach- 

2. (Quality of service: this specifies properties like ability information: prefix =X, groupid =G. Similarly, 
cost, delay, and security in^)lications of using the rout- gateway E (37) would create an Update PDU with 
ing information in this update PDU. prefix =Z and groupid=G. Both of these Update 

3. Path: the routing information that specifies how to 20 PDUs would be distributed to all other gateways ac- 
reach the end systems identified by the prefix(es) in the cording to the IDRP protocol to allow all of them to 
reachability information. learn the association between group G and subnetworks 

Based on received Update PDUs, gateways build X and Z. 
routing tables, called Forwarding Information Bases As reachability information changes (e.g., the prefix 
(FIBs) in IDRP. For each destination (a destination is 25 changes, or groupids are added or deleted), the changes 
identified by a prefix received in an Update PDU, and are reported to the local gateways which use the normal 
may thus be a single node or a set of nodes), the next EDRP routing protocols to update all MPTN gateways 
gateway on the path to that destination is stored (this is with the new information. 

determined from the path field in the update PDU). Construction of Update PDUs as specified above 
Exactiy one path for each prefix is stored for each 30 allows gateways to build an additional routing table 
unique set of quality of service parameters. This path is which will be referred to as the Multicast Routing 
the one that can best provide the specified quality of Table or MURT. The MURT contains for each groupid 
service. the list of prefixes for subnetworks containing members 

In the invention, a new type of reachability informa- of that group, as learned firom Update PDUs containing 
tion is defined, called a group identifier (groupid). A 35 groupids. How the MURT is used for routing is cx- 
groupid is used to address a group of end systems that plained in the next section. 

are to receive a particular set of multicasts. The grou- In the system of FIG. 3, following the distribution of 
pid, which is chosen from the normal subnetwork ad- the Update PDUs as described above, each gateway 
dress space, is therefore included as the destination would have a MURT entry for groupid G, identifying 
address of a multicast packet so that the proper group of 40 X and Z as the prefixes of subnetworks in which group 
end systems is identified. The end systems addressed by members are located. 

a particular groupid are not necessarily located in a The remaining IDRP routing tables (e.g., the FIB as 
common subnetwork. Selecting groupids from the stan- described above) are constructed according to existing 
dard address space guarantees that they represent valid IDRP specifications. In particular the path information 
reachability information even for gateways which do 45 associated with all reachability information ^eluding 
not implement the multicast extensions described be- groupids) is stored in the FIB. 

low. Thus far in this section, the procedure for construct- 

To support unicast inter-domain routing, subnet- ing a MURT using the OSI IDRP routing protocol has 
works report the address prefix(es) shared by its nodes been described. This same procedure can be used with 
to gateways. These prefixes are used to create the Up- 50 any distance-vector routing protocol, as e.g. described 
date PDUs as described above. In the invention, subnet- in the following references: C.L Hadrick, "Routing 
works also report all groupids reachable in that subnet- Information Protocol**, RFC 1038, NIC, June 1988; 
work. R.M. Hinden and A Sheltzer, cited above; K. Loughead 

An example is illustrated in FIG. 3. In that figure, the and Y. Rekhter, cited above; D.L. Mills, cited above. In 
subnetworks with prefixes X (32) and Z (34) also have 55 all such protocols, Update PDUs are distributed to 
end systems in group (9. They therefore report both the advertise reachability to a given address or address 
prefix and the groupid to the local gateways C (39) and prefix. By associating groupids with each address pre- 
E (37). Subnetworitt W (31) and Y (33) do not have any fix, a MURT can be constructed as described above, 
groupids to report, so they report only their prefixes. A MURT can also be constructed using link-state 
Note that a given subnetwork may report multiple 60 routing protocols such as those described in ISO/DiS 
groupids and prefixes (not illustrated). 10589, 1990 or in J. Moy, cited above. In those proto- 

IDRP Update PDUs are constructed as follows. Up- cols, each gateway distributes reachability information 
date PDUs not containing groupids are constructed as in link-state PDUs, which provide information on the 
specified in ISO/DIS CD 10747, mentioned above. state of each link adjacent to that gateway, as well as all 
Update PDUs used to advertise reachability to groupids 65 address prefixes directiy reachable from that gateway, 
must contain the following information: These link state PDUs are forwarded unmodified to all 

An address prefix of the subnetwork, and other gateways in the system. Therefore, by also includ- 

onc or more groupids for that subnetwork. ing a list of groupids in the link state PDUs, a MURT 
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can be constnicted associatiiig the group with a list of 
address prefbces of subnetworks in which group mem- 
bers reside. Both distance- vector and link-state routing 
protocols Create an FIB which is essentially equivalent 
to that created by IDRP. Due to this, the multicast 
forwarding algorithm descnbed in the next section is 
also applicable to these environments. 

Multicast Packet Forwarding 

Conceptually, once the MURT is constructed as de- 
scribed m the previous section, routing of multicast 
packets is very simple. The MURT allows the subnet- 
works in which members of the multicast group are 
located to be identified. Furthermore, the IDRP FIB 
can be used to route packets to each of these subnet- 
works. A copy of each multicast packet could simply be 
routed to each of these subnetworks. However, due to 
the MPTN requirements specified in the section entitled 
Summary of the Invention, above, regarding restric- 
tions on the number of distributed packets, the methods 20 
and algorithms specified in this section are an essential 
part of this invention. 

The invention also defines a Multicast Spanning-Tree 
Algorithm (MSTA) for routing multicast packets in an 
MPTN. The MSTA is also usable in other networks 25 
that provide routing information similar to that speci- 
fied in the previous section. 

To assist the reader m understanding, MSTA is pres- 
ented in an example before the detailed algorithms are 
given. ^ 

The topology of the network used in this example is 
illustrated in FIO. 3. Using the protocols of the previ- 
ous section, the following routing tables are constructed 
at the respective MPTN gateways: 

35 



At gateway A <3S) 

FIB (prefix: next hop on shortest path) 

address prefix W: addresses with this prefix are located 

in the local subnet (31) 
X: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateways 
2: gateway B 
G: gateway B 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 

At gateway B (36) 

FIB (prefix: next hop on litest path) 

W: the next gateway on the path to the subnet 
containing addresses with this prefix is Gateway 
A. 

X: gateway C 
Y: gateway D 
Zi gateway E 
G: gateway £ 
MUEIT (groupid: associated prefixes) 

groi^nd O: the prefixes associated with this groupid are 
X^ 

At gateway C (39) 

FIB (prefix: next hop on shortest path) 

address prefix X: add r esses with this prefix are located 

in the local subnet (32) 
W: the next gateway CD the path to the subnet containing 

addresses whh this prefix is Gateway B. 
Y: gateway D 
Z: gateway B 
G: local subnet (32) 
MUKT (groQpid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X^ 

At gateway D (3S) 

FIB (prefix: next hop on shortest path) 

address prefix Y: addrewrs with this prefix are located 
in the local subnet (33) 



10 

-continued 



W: 



40 



45 



50 



55 



60 



65 



X: 
Z: 
G: 



the next gateway on the path to the subnet containing 
addresses with this prefix is Gateway B. 
gateway C 
gateway B 
gateway C 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groufnd are 
XX 

At gateway E (38) 

FIB (prefix: next bop on shortest path) 

address prefix Z: artdrpsyt with this prefix are located 
in the local subnet (34) 
the next gateway on the path to the subnet contaiinng 
addresses with this prefix is Gateway B. 
gateway B 
gateway B 
local subnet (34) 
MURT Cgroupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X^ 



W: 

X: 
Y: 



The basic layout is shown in FIG. 3. In this example, 
G is the groupid of a multicast group which has mem- 
bers in subnetworks X (32) and Z (34). A source node in 
subnetwork W (31) sends a multicast to groupid G. 

MPTN gateway A (35) receives the multicast packet 
addressed to groupid G from subnetwork W (31), Its 
MURT entry indicates that the multicast is to be sent to 
the subnetworks with prefixes X (32) and Z (34). From 
its FIB, gateway A (35) determines that the next hop for 
both X and Z is gateway B (36). It therefore sends an 
MPTN multicast packet to gateway B (36) with the 
following fields: 

destination =G 

target subnetworks =:X, Z 

data as specified in the original multicast packet 

Note that the target subnetworks field specifies all 
unique destination subn^works for tiiis multicast on a 
given path. Since both subnetworks X (32) and Z (34) 
are reached through gateway B (36), only a single 
packet is sent from gateway A (35) to gateway B (36) to 
accomplish the multicast 

Gateway B (36) receives the multicast packet speci- 
fied above. Since the target subnetworks are specified, it 
does not need to make use of the MURT. Note that this 
impUes that only gateways that are attached to possible 
sources of multicast traffic need to maint-ain a MURT. 
All other gateways do not need to create this table. 
Gateway B uses its FIB to determine that the next hop 
for subnetwork X is gateway C (39) and for subnetwork 
Z (34) gateway E (37). It therefore sends an MPTN 
multicast packet to gateway C with the following fields: 

destination =G 

target subnetworks =X 

data as specified in the original multicast packet 

Note that the target subnetworks field only includes 
those subnetworks on this path. Subnetwork Z (34) is 
reached via a different path and is therefore not in- 
cluded in the multicast to gateway C (39). 

Shnilarly, gateway B (36) sends an MPTN multicast 
packet to gateway E (3^ with the following fields: 

destination =G 

target subnetworks =Z 

data as specified in the original multicast packet 
Gateway C (39) receives the multicast destined for 
subnetwork X (32) to which it is attached. It therefore 
multicasts the packet to groupid G in subnetwork X, 
Similarly, gateway E (37) multicasts the packet in sub- 
network Z (34) to all members of groupid G. Thus the 
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multicast is delivered to all members of groupid G. The 
algorithms above meet all MPTN requirements for 
eHlcient multicast: 

1. The packet was only multicast in subnetworks that 
have a multicast group member (e.g., X and Z, but not 5 
Y). The MURT identifies the destination subnetworks. 

2. Each multicast packet was delivered ejcactly once 
to each subnetwork. The target subnetworks field of the 
MPTN multicast is used to ensure that each subnetwork 
receives exactly one copy of the multicast 10 

3. There are no centralized dements. The creation of 
the MURT, and the routing of multicast packets is com- 
pletely distributed. 

4. The algorithms do not require computation of a 
spanning tree from a topology database. 15 

5. The multicast routing has all the flexibility of nor- 
mal MPTN routing. As shown in the example, the nor- 
mal IDRP FIBs are used to route multicast packets. 
This implies that different routes may be used for differ- 
ent multicast packets due to different quality of service 20 
requirements and/or changing network conditions (to- 
pology or load). 

6. The number of packets distributed is minimized. A 
multicast packet to several destinations (e.g., X and Z) is 
only sent as separate packets when the best routes to the 25 
different destinations are not the same. In the example, 
only a single packet was sent from gateway A to gate- 
way B, but gateway B sent individual packets to gate- 
ways C and E. 

7. The multicast packets are sent on the best route to 30 
each destination according to the IDRP FIB. A unicast 
packet to one of the given destinations would follow the 
same path as the multicast packet to that destination. 

It is also important that only a single MURT entry is 
created per multicast group. The multicast algorithms 35 
for the Internet Protocol described in the Prior Art 
section of this disclosure require nodes to create mul- 
ticast tables with entries for each source-group pair 
(thus the number of entries is multiplied by the total 
number of sources compared to the MPTN scheme). 40 

Having given the above informal description of the 
MPTN multicast packet forwarding algorithm, the pro- 
cedures for multicasting are now specified in detail. One 
procedure is specified for the MPTN gateway that 
initially receives the multicast packet from a subnet- 45 
work (List AX and one for intermediate MPTN gate- 
ways that forward multicasts received from other gate- 
ways (List B). 

List A— Procedure: Initiate— MPTN_Multicast 

This procedure is used by an MPTN gateway that 
receives a multicast packet from a subnetwork. 
Input: The subnetworic multicast packet which speci- 
fies a destination groupid, quality of service, and 
the data to be multicast 55 
Output: MPTN multicast packets to the next gate- 
ways on the path to the target, or a multicast di- 
rectiy to target subnetworks that are directly at- 
tached to the gateway. 
Using the specified groupid as a key into the MURT 60 
obtain the list of prefixes for subnetworks containing 
members of the group. 
For each prefix in the list 

Use the prefix and the specified quality of service as 
a key into the IDRP FIB to determine the next hop 65 
gateway on the path to that subnetwork. 

Add this prefix to a list for the particular next hop. 

For each next hop list created above 



Set target—subnetworks to the list of prefixes associ- 
ated with that next hop. 
Send the MPTN multicast including the groupid, 
target— subnetworks, quality of service, and data to 
that next hop. 
Note that in some cases the target subnetwork is 
directiy attached to this gateway and that the multicast 
is forwarded directiy to that subnetwork in those cases. 

List B — Procedure: Forward— MPTN— Multicast 

This procedure is used by an MPTN gateway to 
forward a multicast packet received from another 
MPTN gateway. 
Input: The MPTN multicast including the groupid, 
target— subnetworks, quality of service, and data as 
created in procedure InitiatCL-MPTN— Multicast. 
Output: MPTN multicast packets to the next gate- 
ways on the path to the target, or a multicast di- 
rectiy to target subnetworks that are directiy at- 
tached to the gateway. 
For each prefix in the received target— subnetworks 
list 

Use the prefix and the specified quality of service as 
a key into the IDRP FIB to determine the next hop 
gateway on the path to that subnetwork. 

Add this prefix to a list for the particular next hop. 

For each next hop list created above 

Set target-subnetworks to the list of prefixes associ- 
ated with that next hop. 

Send the MPTN multicast including the groupid, 
target— subnetworks, quality of service, and data to 
that next hop. 

Note that in some cases the target subnetwork is 
directiy attached to this gateway and that the multicast 
is forwarded directiy to that subnetwork in those cases. 

Multicast with Reduced Routing Information 

In the multicasting scheme described in the previous 
sections, a MURT entry for a group is required at every 
gateway that is attached to a potential source of mul- 
ticast traffic to that group. In large MPTNs with many 
groups, this may be undesirable. Therefore in this sec- 
tion, an alternative scheme is described in which 
MURT entries for a particular multicast group need 
only be maintained at gateways attached to subnet- 
worics with members in that group (other gateways may 
optionally maintftin thcsc MURT entries). This scheme 
can potentially reduce the amoimt of storage required 
to support multicasting at the expense of optimal rout- 
ing, as will be shown. The scheme described in this 
section is an integral part of this invention, and can be 
used in combination with, or in place of the previous 
scheme. 

With this scheme, subnetworks report groupids and 
address prefixes to adjacent gateways as was described 
in the section entitied Routing Information. These gate- 
ways must create MURT entries for the specified grou- 
pids. They must also create IDRP update PDUs as 
described in the addressed section. However, gateways 
not attached to a subnetwork containing members of a 
particular groujud are not forced to maintain MURT 
entries for that groupid. 

Forwarding of packets addressed to a groupid is done 
as follows: 

If a packet to be forwarded has the target subnet- 
works field set by a previous MPTN gateway, it is 
forwarded according to the algorithm in List B. This 
can be done by all gateways since a MURT is not re- 
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quired for this aigoiithm (the destination pre&ies are 
specified in the target subnetworks field). 

If a packet to be forwarded does not have the target 
subnetworks field set, and the destination address is a 
groupid for which a MURT entry is maintained at this 5 
gateway, the procedure for initiating an MFTN mul- 
ticast in List A is followed. 

If a packet to be forwarded does not have the target 
subnetworks field set, and no MURT entry exists for the 
destination address, the packet is forwarded point-to- 10 
point based on the IDRP FIB entry for that address. 

If only the gateways attached to the subnetworks 
with members of a group have a MURT entry for that 
groupid, the packet will be routed point-to-point to one 
of those gateways, which will then cause it to be mul- IS 
ticast to the remainder of the gateways. 

The above algorithm for routing with reduced infor- 
mation is illustrated with an example, again referring to 
the network depicted in FIG. 3. Using the protocols 
specified in this section, the following routing tables are 20 
constructed at the respective MPTN gateways: 



25 



At gateway A (35) 

FIB (piefix: oext hxsp on shortest path) 

address prefix W: addresses witii this prefix are located 

in the local soboet ^1) 
X: the ncKt gateway on the path to the subnet oontaimng 

addresses with this prefix is Gateway B. 
Y: gateway B 
Z: gateway B 

G: gateway B 30 
At gateway B (36) 

FIB (prefix: next hc^ on shortest path) 

W: the next gateway on the path to the subnet 

containing addresses with this prefix is Gateway 
A. 

X: gateway C 35 
Y: gateway D 
Z: gateway E 
G: gateway £ 
At gateway C (39) 

FIB (prefix: next hop on shortest path) 

address prefix X: addresses with this prefix are located ^ 

in the local subnet (32) 
W: the next gateway on the path to the subnet containing 

addresses with this prefix is Gateway B. 
Y: gateway D 
Z: gateway B 
G: local subnet (32) 
MURT (groupid: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
X,Z 

At gateway D (38) 

FIB (prefix: next hop on shortest pa&) 

address prefix Y: addresses with this prefix are located 

in the local subnet ^3) 50 
W: the next gateway on the path to the subnet containing 

addresses with diis prefix is Gateway B. 
X: gateway C 
Z! gateway B 
G: gateway C 

At gateway E (37) 55 
FIB (prefix: next bop on shortest path) 

address prefix Z: addresses wttii this prefix are located 

in the local subnet (34) 
W: the next gateway on the path to the subnet containing 

addresses with ^as prefix is Gateway B. 
X: gateways gQ 
Y: gateway B 
G: local subnet (34) 
MURT (gxoupxl: associated prefixes) 

groupid G: the prefixes associated with this groupid are 
XjZ 

In this example, "G" is the groupid of a multicast group 65 
which has members in subnetworks X (32) and Z (34), 
and it is assumed that only gateways C (39) and £ (37) 
maintain MURT entries for groupid G. Hence» all other 



gateways treat G like a unicast address (i.e., according 
to the existing IDRP procedures), and therefore main- 
tain a single entry for G in their FIBs. The fact that 
multiple gateways advertise a path to G (gateways C 
and E in the example) is not a problem, since IDRP 
allows for this. However, gateways only store routing 
information (in the FIB) for the best path for a given 
prefix. For example, gateway B (36) has a FIB entry of 
gateway E (37) associated with G rather than gateway 
C (39). This could have been reversed, but in any event 
only one of the paths is stored in the FIB. 

MPTN gateway A (35) receives a multicast packet 
addressed to G from subnetwork W (31). it does not 
have a MURT entry for G, so it routes the packet based 
on the FIB entry for G (to gateway B) with the follow- 
ing fields: 

destination =G 

target subnetworks =not set 

data as specified in the original multicast packet 
Note that the target subnetworks field is not set since 
the MURT entry for G is not available. 

Gateway B (36) receives the packet, and since it also 
does not have a MURT entry for G, routes the packet 
based on its FIB to gateway E (37) with the following 
fields: 

destination =G 

target subnetworks =not set 

data as specified in the original multicast packet 

Gateway E (37) is attached to subnetwork Z which 
has members in group G, and therefore it has a MURT 
entry for G. The MURT indicates that the packet is to 
be multicast in subnetworks with prefixes X and Z. 
Since subnetwork Z (34) is attached, it multicasts the 
packet into that subnetwork. Since the FIB entry for 
subnetwork X (32) is gateway B (36), an MPTN mul- 
ticast packet is sent to gateway B with the following 
fields: 

destination =G 

target subnetworks =X 

data as specified in the original multicast packet 

Since the target subnetworks fields is now set, gate- 
way B (36) forwards the packet based on that field 
(contrast the routing decision made here to that made at 
gateway B above). Thus, since the FIB entry for subnet- 
work X (32) is gateway C (39), it forwards the MPTN 
multicast packet to gateway C with the following fields: 

destination =G 

target subnetworks =X 

data as specified in the original multicast packet 
Rnally, gateway C (39) multicasts the packet to grou- 
pid G in subnetwork X (32) to which it is attached. 

Note that in this example the packet was routed 
through gateway B (36) twice; once with the target 
subnetworks field not set, and once with it set. Thus, the 
savings in storage for not maintaining the MURT 
entries at gateways A, B, and D (35, 36, and 38) come at 
the expense of suboptimal routing behavior for mul- 
ticast packets. 

MPTN Use of Multicast 

As noted prcvioudy, MPTN relies on multicasting to 
support multicasts by applications using MPTN, and to 
support MPTN control algorithms. These problems and 
the maimer in which they are solved are described in 
this section. 

Existing routing protocols require that all nodes 
whose addresses have a common prefix be located in a 
single subnetwork. In that way, the prefix uniquely 
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identifies the subnetwork, and operations involving 2. Whenever a gateway becomes aware of the exis- 

nodes with the given prefix can be entirely performed tence of other gateways attached to the same island 

within that subnetwork. This is illustrated in FIG. 4. (which it must in order to implement the existmg rout- 

MPTN allows nodes in different subnetwork to have ing protocols), it examines the addresses of aU such 

the same address prefix Thus, such a prefix does not 5 gateways and uses the smallest such address (which 

uniquely identify a particular subnetwork, and opera- might be its own) as the unique prefix for the split netid. 

tions involving nodes with this prefix may have to be Since all gateways wiU execute this algonthm, they wUl 

distributed over multiple subnetworks. This is illus- converge to using the same address as the prefix to 

trated in FIG. 5. This is referred to as a "split netid", uniquely idaitify this island. 

since '^netid" is a synonym for address prefix, and 10 This step must be repeated whenever a gateway is 

"split" impUes that the nodes with the given netid are «ided or dropped from the set of gateways attached to 

spUt up among different subnetworks. The subnetworks ^ti^ spUt netid island, 

containing nodes in the spHt netid are called '"islands" of T^? ^^^od provides vahd umque prefixes for split 

thatspntnetid.Thus,FIG.5illustratesaspHtnetidwith netid islands m the case where two or more disjomt 

3 isl^ds. Support of such split netids has implications I^^^^^^^^^^H;^?^'^^^!^^^^ 

c 11 - i^T>TXT ^ IS dynamically spht mto several islands. The algonthm 

°r;:SSZ'ulS;^^^ers U, nodes in . is ietel/disUuted and is guan^t^d to^^^^^ 

mg such nodes. 2o The unique address prefixes associated with a split 

2. m order to route comi^CM^d umcast data- , ^ ^ iUustrated in 
grams to a node in a spUt netid, MPTN gateways must ^ 

first determine in which island of the spHt netid the ^ ^ ^^^^ ^.^ ^^^^ p^^^j^ X are 

destination is located. . « located in two different subnetworks. Therefore X, a 

3. Subnetwork protocols that ensure that ^ address^ ^5 spUt netid, is registered as a groupid with the MPTN 
in use in that subnetwork are umque must be extended ^eways attached to those subnetworks. Gateway G 
to all islands of a split netid, smce nodes with the same ^^j) is the only gateway attached to the top island of 
address could exist there due to the use of the same ^^^^^ ^^^^ ^ therefore uses its local address X.7 as the 
address prefix. unique prefix to be associated with groupid X, Gate- 
In order to supped spUt netids, the multicast proto- 3^ ^^yg jj j attached to the lower island 

cols described in this invention are used. In particular ^^^^ ^^^^ gj^^g gateway H's address is less that 

the address prefix common to the nodes in the split netid gateway I's (X.8 is less than X.9), they both use X.8 as 

is treated like a groupid, and this groupid is registered unique prefix to be associated with groupid X. Using 

with all MPTN gateways adjacent to all islands of the protocols of this invention, Gateway F (61) builds 

split netid. Thus, the groupid identifies the group of all 35 ^^e illustrated FIB and MURT table entries associated 

islands of the split netid. User datagrams and connection ^y^^ address prefix X. 

requests will be received that spedfy a destination ad- Using the multicast protocols from the previous sec- 
dress that begins with the split netid prefix 0.e., tiie tions, and tile procedure for mapping spHt netids to 
groupid), since users will want to communicate with groupids and derived netids in this section, it is possible 
resources in that split netid. MPTN control packets will 40 support split netiris in MPTN. 
be addressed to the groupid in order to communicate jf an MPTN user*s packet is to be multicast to aU 
with one gateway attached to each island of the split nodes with prefix X, the packet can be distributed to all 
netid, as explained below. As with other groups, each islands of the split netid using the procedures of the 
group member (lo^ each island) also requires a unique previous sections since X is an entry in the MURT. In 
prefix that will be associated with the groupid in the 45 the same way, flows which are part of subnetworic 
MURT. This is obtained as follows. name management protocols can be multicast to all pads 

Each gateway attoched to a spHt netid has an address Qf a split netid. 
in that subnetwork which is globally unique (this global if a connection or unicast datagram is to be sent to a 
uniqueness is guaranteed by the subna:work protocols). node with prefix X (say X.3 in the example in FIG. 6), 
If this gateway is the only gateway attached to a partic- 50 an additional protocol is required, which forms another 
ular island of the split netid, it may use its own address part of this invention. An MPTN gateway that is re- 
in that subnetwork as the unique prefix for the island. quired to route a unicast packet or connection based on 
Since all routing protocols in the class relevant to this an address prefix which appears in the MURT uses this 
invention (e.g., IDRP, IP, OSPF, OSI IS-IS) require procedure. 

that gateways communicate to exchange routing infor- 55 1. Using the multicast method described in this inven- 

mation, gateways will automatically have contact with tion, a LOCATE request is distributed to one MPTN 

all other gateways attached to the same island of the gateway attached to each island of the split netid. A 

split netid 0.e., all of those gateways with which it parameter of the LOCATE is the specific address 

exchanges routing information through that subnet- which is the target of the original unicast packet (Le., 
work). Thus, gateways are aware when multiple gate- 60 the resource that is to be located). Thus in the example, 
ways are attached to the same island of a split netid, and gateway F (61) multicasts a LOCATE to gateways G 
also when gateways are added or removed from the set (62) and H (63) to determine the location of the resource 

attached to a split netid island, X.3. 

The method for selecting a unique prefix to associate 2. Each gateway that receives such a LOCATE re- 

with an island of a split netid is as follows: 65 quest searches the attached subnetwork (using the na- 

1. When a gateway is initially activated, it assumes tive protocols of that subnetwork, or MPTN protocols) 
that its own address will be used as the unique prefix for to determine if the target resource is actually located in 

the split netid island to which it is attached. that island of the split netid. In the example, gateway G 
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(62)discovers that X.3 is located m the attached subnet- 3. The method of daim 2, wherein the receiving 
woA, while gateway H (63) is not able to locate X.3. stations defined by the group identifier are located in 

3. All gateways that received the LOCATE return a differ^t subnetworks. 

response to the MPTN gateway that initiated the search 4* The method of claim 1, wherein the multicast rout- 
that includes the unique prefix of the responder» and a 5 ing table maintained in a particular gateway node in- 
flag which indicates if the resource was found or not In eludes information of only those receiving stations that 
the example, gateway G (62) returns a response to gate- can be reached via said gateway node, 
way F (61) that includes its unique address prefix 5. The method of claim 2, wherein the multicast rout- 
and a flag that indicates that the resource was found. m table (MURT) maintained in a particular gateway 
Gateway H (63) returns a result indicating that the 10 node includes information of those receiving stations 
resource was not found. that can be reached via said gateway node. 

4. As soon as a positive response to the search is ^ The method of claim 3, wherein the multicast rout- 
obtained, gateway F (61) is able to route the unicast tal>le maintained in a particular gateway node in- 
message or corniection to the proper destination. The ^^^^ infonnation of those receiving stations that can 
header of that request must mdicate to which gateway be r^hed via ^d gateway node. 

the request is being routed (X.7 in the example) so that 7. The method of claim 1, wherem only those gate- 
all gateways can forward the request. The header must way nodes which are connected to possi^^^ 
furAer include the address to which die request is des- ^^^^f ^^^^ mamtam a multicast routmg table of 
tined(X.3)sothatthermalgatewaywinbeabletoroute^^ . , 
it through the subnetwork^ntaining the destination. ^0 8. Tlie method of clami 2 wherem oid^ 

T* vTSr«^««* f 1^^+* ^ way nodes which are connected to possible sources of 

It is unportant for gateways that cannot locate a par- j^J^cast messages maintain a multic^t routing table of 
ticular resource to send a negative response to a LO- Se ad^e^^S^e^^ 
GATE request Otherwise, in the case where the target the addressable receiving stetions. . 
K^K^ ic^ucau wuiuiwi^ 111 Lilt ii^c 6 p method of claim 3, wherem only those gate- 
resource do« not e:^t(e.g., a user attempts to send a ^ ^^^^ ^ comiected to possible sources of 
mc^c to X^5 which does not e^t). the gateway that ^^^^ ^ ^^^^^ ^^^^ ^^^^ 
needs to route the request would wait forever for a addressable receiving stations, 
response. Instead, if a negative r^ponsc is received ^ ^ ^^^^ 
from each gateway, it knows that the resource m ques- ^^^^ ^ connected to possible sources of 
tion is unreachable and it can therefore reject the ongi- ^ multicast messages maintain a multicast routing table of 
nal request • . r r j the addressable receiving stations. 

This terminates the descnption of the preferred em- jy^^ method of claim 5, wherein only those gate- 

bodimcnts. Of course, numerous variations of the given ^^^^ ^y^h are connected to possible sources of 

examples are possible, still within the scope of the m- multicast messages maintain a multicast routing table of 

vention as claimed. 35 the addressable receiving stations. 

We claim; 12. The method of claim 6, wherein only those gate- 

1. A method for multicasting a message from a send- nodes which are coimected to possible sources of 
ing station to a plurality of receiving stations within a multicast messages maintain a multicast routing table of 
conventional unicast message transmission network the addressable receiving stations. 

using existing protocols, said network containing a plu- 40 The method of any one of claims 2, 3, 5. 6, 8, 9, 11, 
rality of subnetworks and a plurality of gateway nodes jj, wherein the group identifier and the correspond- 
connecting, and acting as entry ports to, said subnet- j^g prefixes are transmitted to the gateway nodes to- 
works, said method comprising: gether with conventional routing information, 
distributing multicast group information by each sub- 14, x system for multicasting a message firom a send- 
network to each coimected gateway node, said 45 jng station to a plurality of receiving stations within a 
group information identiiying each group of re- conventional unicast message transmission network 
ceiving stations reachable in said subnetwork; using existing protocols, said network consisting of a 
building and maintaining a multicast routing table in plurality of subnetworks connected by a plurality of 
each gateway node, said routing table containing gateway nodes, said system comprising: 
said group information to enable the routing of 50 means at each of said plurality of gateway nodes for 
multicast messages to each said group of receiving routing multicast messages to a group of receiving 
stations, said multicast routing table having a single stations, said routing means including a routing 
entry for each said group; table having a single entry for each addressable 
transmitting said multicast message with a group group of receiving stations, 
identifier carried in a header part of said multicast wherein each multicast message to be transmitted 
message defining an addressed group of receiving carries a header that contains information defining 
stations; and the addressable group of receiving stations to re- 
in each gateway node, reading and interpreting said ceive said each multicast message, and, 
group identifier transmitted in said multicast mes- means in each gateway node for interpreting, com- 
sage to direct forwarding of said multicast message 60 paring and modifying the header of said each mul- 
to said addressed group of receiving stetions. ticast message. 

2. The method of claim 1, wherein the group informa- 15. The system of claim 14v wherein said plurality of 
tioii in the multicast routing table at each gateway node subnetworks are of different types and use different 
contains at least one prefix corresponding to each group message transmission protocols. 

identifier identifying each subnetwork in which the 65 16. The system of claim 15, wherein only a subset of 
addressed group of receiving station(s) is located, and said plurality of subnetworks is equipped to support 
wherein said header part of each said multicast message multicasting, 
contains said corresponding prefix. ***** 
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